[Kinesis] Lambdaのイベント設定時、開始時刻(AT_TIMESTAMP)の指定が可能になりました
はじめに
AWSチームのすずきです。
2016年12月のアップデートにより、LambdaのイベントソースとしてKinesis Streamsを利用する際、 「AT_TIMESTAMP」、指定時刻以降に登録されたレコードを対象とした利用が可能となりました。
今回、Lambdaのサンプルコードを利用し、イベントソースのKinesis Streamsから 指定時刻以降に登録されたデータの取得を試みる機会がありましたので、紹介させていただきます。
手順
Lambda関数作成
サンプルコードの選択
- AWSのマネジメントコンソール上でBlueprintとして公開されている、 Lambdaのサンプルコード(kinesis-process-record-python)を利用しました
Lambda関数設定
- コードはサンプル、ロールはデフォルト(Create new role from template)のものを利用しました。
トリガ設定
- データ登録済のKinesis streamsを、データソースとして指定します
- Starting Positionとして、今回利用可能となった「At timestamp」を指定します
- 時刻(Timestamp)は、UTCで指定します。
トリガ有効化
- トリガを有効化し、Lambda関数を実行します。
Lambda実行結果の確認
- Cloudwatch Logsのログを確認します。
- ログストリームを確認します
ログ出力結果
- ログストリームを指定し、最も古いレコードに遡ります。
- 指定時刻(UTC時刻で12/7 12時、JTCでは12/7 21時)以降のレコードから、処理が開始された事が確認できました。
- レコードに記録された時刻情報はデータ送信元の時刻をJSTで示します。
- Kinesis送信前のバッファリングや、送信完了までのタイムラグが存在します。
まとめ
従来、Kinesis StreamsをLambdaのイベントソースとして利用する場合、取得開始地点の指定は、
- TRIM_HORIZON : ストリームに存在する最も古いレコード
- LATEST : 現在以降に登録されたレコード
から選択する必要がありました。
しなしながら、多くのレコードが登録されるストリームや、ストリーム上のデータ保存期間を延長していた場合には、 TRIM_HORIZONでは対象データが多くなりすぎ、エラー発生時に再処理が困難。 また、データの登録元が夜間に停止するなど、稼働時間が限定されるシステムでは、データが届かない時間の検証が 難しいこともありました。
- AT_TIMESTAMP : 指定した時刻以降にストリームに登録されたレコード
の利用、APIやCLIでは2016年春より利用可能となっていた機能でしたが、Lambdaでも利用が可能となった事で、 べき等性の確保が容易となり、運用性や開発効率の向上が期待できます。
先日リリースされたLambdaのDLQ対応など、確実に進化を続けるAmazon Kinesis。これからも注目です。